Telecommunications system

ABSTRACT

There is described a system which, in a voice over IP radiotelecommunications system, allows a mobile station to make an emergency call, even though other calls would not be allowed at that time.  
     The mobile station includes an emergency call indication in the session activation request, and this is recognized by the network nodes, which then allow call set up.

TECHNICAL FIELD OF THE INVENTION

[0001] This invention relates to a telecommunications system, and to amethod of operation thereof. More particularly, the invention relates toa telecommunications network using Internet Protocol (IP), andspecifically to a system for handling emergency calls in such a network.

BACKGROUND OF THE INVENTION

[0002] In mobile communication systems, there are situations in which acall request may not be allowed. For example the user may not have paida bill, or the mobile system may have no information at all about theuser, or there may be congestion on the network, or the mobile phone maybe reported stolen.

[0003] In the GSM system, emergency calls may be allowed even when oneof these factors apply.

[0004] It is expected that 3^(rd) generation (3G) mobile phones willallow voice over IP. That is, the Internet Protocol (IP) will be usedfor the whole call from the mobile phone to the network gateway which isthe connection to the public switched telephone network (PSTN) whichincludes the emergency services operator. Therefore, all calls will sendthe voice signals as packet data, rather than as circuit switched data.

[0005] The document “GSM on the Net”, by Granberg, Ericsson Review No.4, 1998 pages 184-191, describes a voice over IP system, based on therecommendation ITU H.323. The H.323 protocol separates call control(signalling in the call setup phase) from connection control (the actualdata flows).

[0006] However, it provides no mechanism to allow for special treatmentof emergency calls.

SUMMARY OF THE INVENTION

[0007] The present invention is concerned with allowing specialtreatment of emergency calls, so that such a call can be successful eventhough another voice call would not be allowed.

[0008] According to one aspect of the invention, a mobile communicationdevice analyses a dialled number and, in the case of an emergency call,sends a session activation request which includes an emergency callindication.

[0009] According to another aspect of the invention, a node in a packetdata communication network detects an emergency call indication in asession activation request, and allows call setup, even though a callwithout such an indication would fail.

[0010] According to another aspect of the invention,

BRIEF DESCRIPTION OF DRAWINGS

[0011]FIG. 1 is a diagram illustrating message flows during call setupin accordance with the invention.

[0012]FIG. 2 is a flow chart showing a method carried out in a mobilephone in accordance with the invention.

[0013]FIG. 3 is a schematic representation of a mobile phone inaccordance with the invention.

[0014]FIG. 4 is a diagram illustrating message flows during call setupin accordance with a second embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0015] In accordance with the invention, when a mobile phone wishes toplace an emergency call, it sets a special emergency call indicationwhen requesting mobile system and radio resources.

[0016]FIG. 1 shows the network components required to connect a 3^(rd)generation mobile phone to an emergency services operator. A radionetwork controller (RNC) controls the air interface with a mobilestation 10, and operates in the Universal Mobile Telephony System (UMTS)or using Wideband Code Division Multiple Access (WCDMA). The networkoperates using the General Packet Radio System (GPRS), and includes aServing GPRS Service Node (SGSN) and a Gateway GPRS Service Node (GGSN).The GGSN is connected to a call server in the IP multimedia domain, andthis is further connected to a gateway, which is connected to the publictelephone network, operating for example as a Public Switched TelephoneNetwork (PSTN) or Integrated Services Digital Network (ISDN) system. Theemergency services operator is connected to the public telephonenetwork.

[0017] The call setup procedure is also shown in FIG. 1, while FIG. 2shows the procedure in the phone, and FIG. 3 is a representation of aphone 10. The procedure is described further with reference to theSession Initiation Protocol (SIP), described in IETF document IETF/RFC2543. This protocol is part of the IETF multimedia data and controlarchitecture, and can be used to set up calls between parties.

[0018] As shown in FIG. 1, a user enters a dialled number, for examplevia a keypad 12, which is sent to a controller 14, which then forms amessage to be sent via transceiver circuitry 16 through an antenna 18.

[0019] In the controller 14, the dialled number is received (step 20 inFIG. 2), and the controller recognises from the dialled digits (forexample, the numbers 112, 911 or 999), that the call is an emergencycall. The session activation request which is then sent (step 24, andalso see FIG. 1) is then handled accordingly.

[0020] The mobile phone has to activate a packet (IP) data communicationsession with the mobile GPRS system over the air interface. A first PDPactivation (Activate PDP Context Request, according to the GSMrecommendation 24.008) is sent from the mobile station to the SGSN toget a signalling radio bearer. When this has been obtained, the mobilestation sends a second PDP activation to the SGSN, stipulating the needfor a voice communication, allowing the user to speak to an operator atan emergency centre. The second PDP activation includes the requestedbandwidth, delay and other quality of service parameters. These tworadio bearers remain in parallel until the call is dropped.

[0021] In the illustrated embodiment of the invention, the twoactivation messages each include an indication that this is an emergencycall. In the context of the GSM recommendation 24.008, the emergencyindicator could for example be set by setting the Access Point Name(APN) to “EMERGENCY”, Or something similar.

[0022] Thus, in more detail, the first session activation request isreceived by the 3G GPRS SGSN element. The SGSN recognises the receivedemergency call indication, and the SGSN will then not stop the callsetup process, even if it would normally fail, for example because itcannot obtain user profile data or if unsuccessful authenticationoccurs.

[0023] The SGSN will send a Create PDP context request to the GGSN ofthe same network as the SGSN, to create a packet session with it. Thecontext request will contain the special indication about an emergencycall, received from the mobile phone as described above. This opens acommunication path between the SGSN and the GGSN for this particularemergency call.

[0024] Since the GGSN has received the emergency call indication fromthe SGSN, the GGSN will determine the identity of the locallygeographical VoIP call server that should receive forthcoming callcontrol signals from the mobile phone. This can be done by software inthe GGSN. This has the advantage that the call is routed out from themobile system and to the public network emergency centre as fast aspossible. This avoids the possibility that the call could be routed tothe call server belonging to the home network of the user. If the useris roaming, this could conceivably be in another country.

[0025] This call server identity is thereafter returned by the GGSN tothe SGSN in the acknowledgement message which relates to the firstactivation message. The call server identity can be an IP address inconventional format.

[0026] The SGSN then returns the call server identity back to the mobilephone, for example in the acknowledgement signal to the first ActivatePDP context request message.

[0027] When the mobile phone gets a successful session activationacknowledgement from the mobile system, the mobile phone can start thevoice over IP (VoIP) related call control signalling over the session.In this described embodiment, this call control signalling is asdescribed in the IETF Session Initiation Protocol (SIP). The firstsignal, that is, the INVITE signal in SIP, will include the VoIP callserver identity determined by the GGSN and received from the SGSN. Whenthe mobile terminal receives the call server identity in the format ofan IP address, the mobile terminal should set this address in the IPpacket header “destination address” field at all times when sending SIPmessages, including the INVITE message. In this way, network routerswill route IP packets that are carrying such SIP messages, directed tothe call server, correctly to the call server.

[0028] The call server can also typically be the same as handling allthe normal VoIP calls as well. The initial message, for example the SIPINVITE message, includes an emergency indication as well, either thenumber dialled by the user e.g. 112 in a 3G UMTS European system or 911in a 3G UMTS North America system, or a separate emergency indication.Alternatively, a new message could be defined, for example a SIPEMERGENCY INVITE message. Including the emergency indication avoids thepossibility that the call server could treat the call as a normal voicecall, with the possibility that it could stop the call process in theevent of a failure to continue.

[0029] The call server then places an ISUP call to the appropriate PSTNsignalling/media gateway for the emergency services operator usingISUP/IP, which routes the call using ISUP/SS7 to the operator. Then, asis conventional, a ringing response is sent using ISUP to the gateway,and using SIP to the call server and then to the mobile station. Theresponse includes the address of the gateway.

[0030] This can then be used by the mobile station to create therequired voice bearers to carry speech to the emergency servicesoperator with the desired parameters, using the gateway address so thatspeech packets can reach the gateway. Thus, the mobile terminal sends asecond Activate PDP Context request message, including an emergencyindication, to the SGSN, which sets up a radio access bearer with themobile terminal, and also sends a Create PDP Context request to theGGSN.

[0031] The GGSN responds to this message, and the SGSN sends an ActivatePDO Context accepr message to the mobile terminal, after which a speechpath is established between the mobile terminal and the emergencyservices operator.

[0032]FIG. 4 illustrates a second call setup process according to theinvention.

[0033] In the same way as FIG. 1, FIG. 4 also shows the networkcomponents required to connect a 3^(rd) generation mobile phone to anemergency services operator, namely a radio network controller (RNC)controlling the air interface with a mobile station 10. The networkoperates using the GPRS system, and includes a SGSN and a GGSN. The GGSNis connected to a call server in the IP multimedia domain, and this isfurther connected to a gateway, which is connected to the publictelephone network, operating for example as a PSTN or ISDN system. Theemergency services operator is connected to the public telephonenetwork.

[0034]FIG. 4 shows the set up of an emergency call from a mobilestation, when the mobile station does not contain a Subscriber IdentityModule (SIM) card. In that case, it is conventionally not possible toinitiate a call.

[0035] As in the procedure described with reference to FIG. 1, themobile phone has to activate a packet (IP) data communication sessionwith the mobile GPRS system over the air interface. In this case, whenthe mobile phone is without a SIM, it is permitted to form a limitedattach. Thus, the mobile station sends an attach request via the RNC tothe SGSN. In the attach request, the International Mobile StationEquipment Identity (IMEI) is transmitted as the mobile identity, andthere is no Routing Area Indentification (RAI) or Ciphering Key SequenceNumber (CKSN). An alternative is that the attach request should beallowed to be sent without any mobile identity.

[0036] In this embodiment of the invention, the only service allowedafter formation of a limited attach is an emergency call. Therefore, thereceipt by the SGSN of an attach request with the IMEI as the onlyidentifier is a preliminary indication that an emergency call isrequired.

[0037] The formation of a limited attach is allowed in some situationswhere a normal attach would not be allowed, including in this case whereno SIM is available. A normal attach should be used if possible. In theprocedure illustrated in FIG. 4, the SGSN accepts the formation of thelimited attach, and returns an attach accept message to the mobilestation, with a Temporary Mobile Station Identifier (P-TMSI), and aRandom Access Identifier (RAI).

[0038] The SGSN does not need to contact the Home Location Register(HLR) of the mobile station subscriber. Moreover, the SGSN does notperform any authentication or ciphering.

[0039] Thereafter, a request is sent from the mobile station to the SGSNto get a signalling radio bearer. When this has been obtained, themobile station sends a second PDP activation request to the SGSN,stipulating the need for a voice communication, allowing the user tospeak to an operator at an emergency centre. The second PDP activationincludes the requested bandwidth, delay and other quality of serviceparameters. These two radio bearers remain in parallel until the call isdropped.

[0040] Preferably, the two activation messages each include anindication that this is an emergency call. In the context of the GSMrecommendation 24.008, the emergency indicator could for example be setby setting the Access Point Name (APN) to “EMERGENCY”, Or somethingsimilar.

[0041] Thus, in more detail, the first session activation request isreceived by the 3G GPRS SGSN element. The SGSN recognises the receivedemergency call indication, and the SGSN will then not stop the callsetup process, even if it would normally fail, for example because itcannot obtain user profile data or if unsuccessful authenticationoccurs.

[0042] The SGSN will send a Create PDP context request to the GGSN ofthe same network as the SGSN, to create a packet session with it. Thecontext request will contain the special indication about an emergencycall, received from the mobile phone as described above. This opens acommunication path between the SGSN and the GGSN for this particularemergency call.

[0043] Since the GGSN has received the emergency call indication fromthe SGSN, the GGSN will determine the identity of the locallygeographical VoIP call server that should receive forthcoming callcontrol signals from the mobile phone. This can be done by software inthe GGSN. This has the advantage that the call is routed out from themobile system and to the public network emergency centre as fast aspossible. This avoids the possibility that the call could be routed tothe call server belonging to the home network of the user. If the useris roaming, this could conceivably be in another country.

[0044] This call server identity is thereafter returned by the GGSN tothe SGSN in the acknowledgement message which relates to the firstactivation message. The call server identity can be an IP address inconventional format.

[0045] The SGSN then returns the call server identity back to the mobilephone, for example in the acknowledgement signal to the first ActivatePDP context request message.

[0046] When the mobile phone gets a successful session activationacknowledgement from the mobile system, the mobile phone can start thevoice over IP (VoIP) related call control signalling over the session.In this described embodiment, this call control signalling is asdescribed in the IETF Session Initiation Protocol (SIP). The firstsignal, that is, the INVITE signal in SIP, will include the VoIP callserver identity determined by the GGSN and received from the SGSN. Whenthe mobile terminal receives the call server identity in the format ofan IP address, the mobile terminal should set this address in the IPpacket header “destination address” field at all times when sending SIPmessages, including the INVITE message. In this way, network routerswill route IP packets that are carrying such SIP messages, directed tothe call server, correctly to the call server.

[0047] The call server can also typically be the same as handling allthe normal VoIP calls as well. The initial message, for example the SIPINVITE message, includes an emergency indication as well, either thenumber dialled by the user e.g. 112 in a 3G UMTS European system or 911in a 3G UMTS North America system, or a separate emergency indication.Alternatively, a new message could be defined, for example a SIPEMERGENCY INVITE message. Including the emergency indication avoids thepossibility that the call server could treat the call as a normal voicecall, with the possibility that it could stop the call process in theevent of a failure to continue.

[0048] The call server then places an ISUP call to the appropriate PSTNsignalling/media gateway for the emergency services operator usingISUP/IP, which routes the call using ISUP/SS7 to the operator. Then, asis conventional, a ringing response is sent using ISUP to the gateway,and using SIP to the call server and then to the mobile station. Theresponse includes the address of the gateway.

[0049] This can then be used by the mobile station to create therequired voice bearers to carry speech to the emergency servicesoperator with the desired parameters, using the gateway address so thatspeech packets can reach the gateway. Thus, the mobile terminal sends asecond Activate PDP Context request message, including an emergencyindication, to the SGSN, which sets up a radio access bearer with themobile terminal, and also sends a Create PDP Context request to theGGSN.

[0050] The GGSN responds to this message, and the SGSN sends an ActivatePDO Context accepr message to the mobile terminal, after which a speechpath is established between the mobile terminal and the emergencyservices operator.

[0051] It should be noted that, although the invention has beendescribed with particular reference to a GPRS based mobile telephonesystem using the IETF SIP, it is applicable to any mobile communicationsystem, which offers real-time packet (IP) data communication, with anytype of call control protocol, including for example ITU-T H.323.

[0052] There is thus described a method which allows an emergency callto be placed even when other calls would not be allowed.

1. A mobile communications device, capable of operating in a packet datacommunications network, the device comprising: means for analysing adialled number, the device being adapted, in the event that a diallednumber is indicative of an emergency call, to send a session activationrequest which includes an emergency call indication.
 2. A mobilecommunications device as claimed in claim 1, the device being adapted tosend the session activation request, in the event that a dialled numberis indicative of an emergency call, even if the device has no SIM.
 3. Amethod of handling an emergency call in a mobile device capable ofoperating in a packet data communication network, the method comprising:analysing a dialled number; and if the dialled number is indicative ofan emergency call, sending a session activation request which includesan emergency call indication.
 4. A method as claimed in claim 3,comprising sending the session activation request if the dialled numberis indicative of an emergency call, even if the mobile device has noSIM.
 5. A network node for use in a pocket data communications network,the node comprising means for detecting an emergency call indication ina received session activation request, and being adapted, in the eventthat an emergency call indication is detected, to set up a call even ifnormal call setup criteria are not met.
 6. A node as claimed in claim 5,wherein the mode is a SGSN element.
 7. A node as claimed in claim 6,wherein the node is adapted, in the event that an emergency callindication is detected, to set up a call even if the received sessionactivation request includes no mobile station identifier.
 8. A node asclaimed in claim 6, adapted, in the event that an emergency callindication is detected, to create a packet session with a GGSN,including a further emergency call indication.
 9. A node as claimed inclaim 5, wherein the mode is a GGSN element.
 10. A node as claimed inclaim 7, adapted, in the event that an emergency call is detected, toreturn a message indicating a call server local to a calling device. 11.A method of operation of a node in a packet data communications network,the method comprising: detecting an emergency call indication in areceived session activation request, and if an emergency call indicationis detected, setting up a call even if normal call setup criteria arenot met.
 12. A method as claimed in claim 11, wherein the mode is a SGSNelement, and the method further comprises: if an emergency callindication is detected, creating a packet session with a GGSN, includinga further emergency call indication.
 13. A method as claimed in claim11, wherein the mode is a SGSN element, and the method furthercomprises, in the event that an emergency call indication is detected,setting up a call even if the received session activation requestincludes no mobile station identifier.
 14. A method as claimed in claim11, wherein the mode is a GGSN element, and the method furthercomprises: if an emergency call indication is detected, returning amessage indicating a call server local to a calling device.